跳到主要内容

对于移动目标的一种偏见：复杂分析（A Biased Take on a Moving Target: Complex Analytics）

由 Michael Stonebraker 介绍

本篇文章没有被选中的读物

在最近的5～10年里面，新的分析工作复杂性已经拓展了许多，超出了传统的商业智能分析（BI）的用例。举例来说，互联网的广告提供商可能会想着了解，“在过去四天之中，购买了苹果电脑的女生，与同一时期，购买了福特汽车的女生，从统计数据上面来看，有无存在不同？”。而下一个问题则可能是："在我们的下一个广告之中，根据广告的点击率，向那些福特汽车的买家展现哪一方面内容，最为合适?"。这些问题由当今世界中的数据科学家提出，同时与以商业智能分析应用中运行着的传统的 SQL 分析语句差别相当大的用例呈现着。一种普遍的看法在于，数据科学将会在未来的十年，或者二十年内，完全取代商业智能，因为它，代表了一种更为复杂的，对数据仓库中的数据展开挖掘，以便获取新的数据理解方式的路径。基于上述的看法，这篇文档之中，将会集中面向数据科学家的需求。

在这一章节中，我将会开始阐述，我对于数据科学家工作性质的认知与理解，在清理与整理其数据之后，数据科学家往往将会执行下面的迭代进程，而这也占据了他的工作当中的绝大部分的时间，我们在数据集成的部分已经对此进行了讨论，一般而言，数据科学家将会执行如下的迭代：

Until (tired) {
Data management operation(s);
Analytic operation(s);
}

还而言之，他持有着一个迭代着的发现过程，而在这个过程之中，他会对数据进行分离，提取出感兴趣的部分来，同时他将会对于数据执行一定的分析操作。而这，通常也就意味着，要么，我们会对于不同的数据集合，执行相同的操作，要么，我们会对于相同的数据集合，执行不同的分析操作。总而言之，数据科学与商业智能分析的一个主要的区别在于，数据科学，往往提供的是预测建模，机器学习，回归测试...而并非 SQL 分析。

一般而言，分析会经由一组由计算构成的流水线管道组成。举例来说，Tamr 设计了一个模型，它可以对一组大规模的N个记录实体整合（对重复数据进行清理）。而出于避免暴力算法所带来的 N^2 复杂性，Tamr 识别出来了一组“特征”，并且将他们划分到互不相交的范围之中，同时根据范围的情况计算每一条记录的二进制值（“bin”），并且以并行的方式根据二进制值，对他们进行分区，消除重复的二进制值，同时整合结果，并在最后从各种重复的数据当中，构建复合的记录。这个管道，部分面向 SQL（分区），而另外一个部分，则是以数组方式展开的数据分析。Tamr 似乎在这个过程之中，展现出了一名数据科学家的典型工作负载，因为在这条管道之中，包含六个步骤的管道。

一些数据的分析管道，是“短时间的“，它们一次可以在一组批处理上面运行。不过，绝大多数的生产用应用程序，会自然而然地保持增长。举例来说，Tamr 的模型在最初的一批输入记录上面运行，而随着新的或者修订后的输入记录的到来，它就必须按照一定的周期，来处理这些新的“数据段”。而执行增量的操作，存在两种办法。如果增量以一天的周期性间隔被批量处理为“小数据段”，那么就可以把下一个增量添加到先前处理的批量之中，并且，在每一次输入更改的记录的时候，对于整个数据处理管道，展开一个运行。而对于计算资源而言，这样的策略，无异于极度的浪费。与之相对的地方在于，我们将会集中于在初始批处理运行操作之后的增量算法的运行情况。这种增量算法，要求可以把每一次交互时分析的中间状态，存储于持久的存储之中。尽管，Tamr 的流水线大约为 6,但是每一个步骤，都应当保存到持久存储之中，以便支持增量的操作。因为保存状态是一种数据管理操作，这就使得长度为1的数据分析管道，成为一种可能。

而最终的“实时”解决方案，就是通过流数据的平台，来不断运行增量的数据分析服务，这就与我们在新 DBMS 技术中的一节中所讨论的那样。而根据新的记录的到达率，我们就可以选择其中的一种解决方案。

绝大多数的复杂数据分析是数组面向的，也就是说，它们是定义在其上的线性代数运算的集合阵列。而有一些数据分析，是以图数据为导向的，例如社交网络的分析。一件显然的事情在于，数组可以在基于数据表的系统上面模拟出来，而图则可以在数据表系统与数组的系统上面模拟出来。在这种情况下面，在本篇文档的后面，我们将会讨论，这个用例下面，需要应用到多少种不同的体系结构。

一些问题，涉及到密集的数组阵列，也就是说，每一个数组的单元，都有一个数值的阵列。比如，伴随着时间的推移，纽约证据交易所所有证劵的收盘股价都将会是密集的，因为每一只股票，在每一个交易日都会有着收盘的价格。而从另外一个方面来看，一些问题将会是稀疏的。比如，以矩阵表示出来的社交网络用例，将会具有以某种方式关联的每一对人的单元格数据。而显然地，这个矩阵将会是非常稀疏的。稀疏矩阵的数据分析与密集矩阵的数据分析，将会存在极大的差别。

在这个篇章中，我们将会讨论大规模伸缩性的工作负载。而如果有人希望可以在“小规模数据集合“应用这样的数据流，那么任何的解决方案，都将会顺利工作。

数据科学平台的目标在于，支持这个遍历发掘的过程。我们首先，将会想你展现一个悲伤的现实。也就是说，绝大多数的数据科学平台，都是基于文件的，同时与 DBMS 无关。这些分析代码的优势在于，它们可以在 R,MatLab，SPSS，SAS 以及文件数据当中运行。补充来说，许多的 spark 用户从文件当中读取数据。这种情况的一个案例就在于，劳伦斯伯克利大学实验室中的 NERSC 高性能计算（HPC）系统。这台机器，基本上只会被用于复杂的数据分析。但是，由于配置本身的限制，我们无法在上面运行 Vertica 数据库。除此之外，绝大多数的“大科学”项目都是从一无所有开始构建出一个完整的软件堆栈的。这种情况可能会一直持续下去，由此使得数据库不会成为这个市场的参与者。不过，也存在着许多有着希望的迹象，比如基因数据开始部署于数据库管理系统上面，比如，1000 基因组项目，就是基于 SciDB 的。

在我的观念之中，文件系统存在着几个很大的缺点。首先，元数据（标记、时间等）并没有在文件的名称当中存储着或者编码着，这样就使得文件系统的可搜索性相当弱。第二，在数据科学工作负载当中的数据管理部分当中，复杂的数据处理工作并不可用，它必须（以某种方式）手动编写出来。第三，文件数据在同事之间的相互交换非常复杂。就我所知道的事情而言，存在着数个项目，将它们的数据与其配套的解析程序一同导出。而接收数据的人可能无法重新编译出这个解析器程序，或者在构建的过程中得到一个错误。而在接下来的讨论当中，我将会假设，伴随着时间的推移，数据科学家们将会希望使用数据库科学技术。因此，我们将不会再讨论基于文件系统的解决方案。

在这个背景之下，我们在数据表1当中，展现了数据科学平台的分类。而基于我们上面所提出来的假设，为了实现数据的管理部分，我们需要一款数据库。这个数据库可以拥有一个或者两个故障转移节点。首先，它可以像在关系型行存储或者NoSQL引擎当中那样，以面向记录的方式展开工作，或者像在大多数的数据仓库系统中那样，采用面向列的方式来展开工作。在这些场景之中，数据库的数据结构，并不聚焦于数据分析的工作需要，数据分析工作往往是面向数组的，因此这方面更加自然的选择，往往就是数组数据库。而后一种用例情况的优势在于，执行记录并不需要从记录或者列结构当中进行转化。因此，阵列数据结构，在性能上面，具有天然的优势。补充来说，相较于通常是一维的数据表结构，面向阵列的存储结构本质上是多维数据结构。同样的，它可能会带来更高的性能。

而第二个维度，则涉及数据分析与数据库之间的耦合。一方面，它们之间可以相互保持独立，同时可以在上面运行一个对应的查询，并将查询的结果复制到另外一个不同的，数据分析运行于其上的地址空间之中。而在数据分析管道的最后（它们的长度通常为1），其结果可能会被写回到持久存储之中。而这种做法将会导致数据库与数据分析的大量数据流失。而另外一个方面来说，我们可以把数据分析以用户定义函数的方式，放在数据库相同数据空间的地址加以运行。显然，紧密耦合的可替代方案将会降低数据的流失程度，同时将会带来更好的性能。

在这种情况之中，存在四种单元格，记录于数据表一之中。左下侧的角落之中，Map-Reduce 在过去的年代当中，曾经就是典范；而到了最近，Spark 已经超越了 Map-Reduce，成为最受关注的平台。在 Spark 当中，没有持久性机制，因此它依赖于 Red-Shift 或者 H-Base，亦或是其它的接口来实现这个目的。因此，在 Spark 之中，一个用户可以在一些数据库当中执行查询，以此来构建数据集合，它被加载进入到 Spark 当中，而数据分析的工作，随即也就会在这里展开。而由 Spark 提供支持的数据库，往往都是面向记录的，或者是面向列的，因此对于数据分析而言，提供一种将它们转换为阵列结构表示的方法，相当必要。

而在右下侧角落当中的一个明显案例，就是 MADLIB[^85]，它是一个由面向对象型数据库 Greenplum 提供支持的用户自定义函数库。其它的供应商在最近已经启动了一些其它的替代解决方案；比如，Vertica 支持在R语言当中，使用用户自定义函数。而在右上侧的角落之中，则是一些内建了数据分析的阵列系统，比如 SciDB[^155], TileDB[^56], 或者是 Rasdaman[^26]。

而在这篇文档当中的剩余部分，我们则会集中讨论性能方面所带来的影响。首先，当我们从数据表1的的左下角移动到右上角的时候，一件可以期待的事情就在于，性能将会有所提升。其次，绝大多数复杂的分析，都可以简化为一小部分的“内环的”计算，比如矩阵的乘法，奇异值的分析，以及QR（二维码）的分解。它们都属于计算密集型的，且以浮点代码来进行表示。而绝大多数的人都认为，特定于硬件的流水线技术，可以在这一类代码的性能上面，产生几乎是一个数量级的差异。因此，形如 BLAS，LAPACK, 以及 SacLAPACK 这样的库，往往被称为面向硬件优化的英特尔 MKL 库，它们将会比那些没有使用硬件优化的代码，快上很多。当然，硬件优化将会对密集的阵列计算，产生非常巨大的影响，而其中的大部分工作，都会反映在浮点的计算之中。而这些事情，对于稀疏阵列的意义，不是很大，因为索引的问题，可能会主导计算的时间。

第三，提供估算答案的代码，比提供精确答案的代码要快速上许多。如果你的工作可以使用估算方案解决的话，那么你就可以节省下许多时间来。

第四，高性能的计算(HPC)，一般而言都被配置为可以支持大规模的批处理工作。因此，它们通常被构造为可以通过网络，连接到存储服务器的计算服务器，因此，程序必须在计算服务器缓存中，预先分配好磁盘的空间，以便满足存储的需求。而这显然地，与数据库不一致，后者更希望作为服务而持续运行着。因此，请注意，在高性能计算环境中，使用数据库系统，可能会遇到更多的问题。一个引人深思的感兴趣的探索领域，就是高性能计算机器能否可以在不牺牲性能的情况下面，同时处理好交互式与批处理的工作负载。

第五，可拓展的数据科学代码总是在计算机网络当中的多个节点上面运行，并且通常与网络相互绑定[^55]，在这种情况之下，对于网络成本必须深刻谨慎，而 TCP/IP 在这种情况下，可能并不是一个好的选择。而一般而言，MPI 是一种更高性能的替代方案。

第六，绝大多数的，由我们测试过的数据分析代码，都不能够拓展到大的数据集合大小，这要么是因为，它们耗尽了主内存的空间，要么在于，生成它们所需要的临时空间太大。因此，请务必确保，对于所有可能会在生产平台下运行的数据集合，您展开了一个相关的测试。

第七，你的数据分析管线的组织结构非常关键。如果你的流水线的长度为1，那么对其进行紧密的整合，就是一个良好的想法。而从另外一个方面来看，如果管线的长度为10,松散的整合将会在绝大多数情况下，发挥良好。在递增的操作之中，一般我们期待的管线长度就是1。

一般而言，所有由我们所知道的解决方案，都存在着伸缩性以及性能方面的问题。更进一步的说，上面我们所提供的绝大多数的案例，都针对于快速移动的目标，因此性能与伸缩性无疑将会得到一定的改善。简要来说，看看表1当中，究竟哪一些单元格里面的软件有配套，而哪一些没有，是一件非常有趣的事情。商业市场，将会成为这个问题最终的裁决者！

在我的观念当中，复杂的数据分析在当前的情况下，依旧处于“狂野西部”（也就是存在着广阔的机会，译者注）阶段，因此我们希望下一个版本的红皮书，能够确立出一系列核心的开创性论文来。与此同时，我们依旧需要展开大量的研究工作。具体来说，我们将会鼓励在这个领域当中，展开更多的基准测试，以便发现既有平台的缺陷来，进而促进进一步的研究和开发工作，尤其是研究涉及数据管理和分析的端到端任务的基准测试的时候的时候。这个空间变化迅速，因此其基准的测试结果，可能具有瞬时性。这可能会是一件很好的事情：因为我们正在处于一个各个项目应当相互学习的阶段。

目前，人们对那些用于核心分析任务（如凸优化）的自定义并行算法非常感兴趣；其中一些，来自于数据库的社区，看一看这些算法是否可以整合进入到分析型数据库管理系统当中，将会是一件有趣的事情，因为它们通常不遵循传统的数据流执行风格。这里的一个例子，就是 Hogwild![^133]，它依托共享内存中的无锁并行性，来实现高性能。而谷歌的 Downpour[^49]，以及微软的 Project Adam[^39]，都将这一基本的思想，应用到了深度学习的分布式环境之中。

目前，人们对用于核心分析任务（如凸优化）的自定义并行算法非常感兴趣；其中一些来自数据库社区。看看这些算法是否可以合并到分析数据库管理系统中会很有趣，因为它们通常不遵循传统的数据流执行风格。这里的一个例子是霍格威尔！[133]，它通过允许共享内存中的无锁并行性来实现非常快的性能。谷歌的Downpour[49]和微软的Project Adam[39]都将这一基本思想应用于深度学习的分布式环境。

而另外一个有待探索的领域，就是内存溢出算法（out-of-memory algorithms）。例如，Spark 希望我们的数据结构，可以适应集群当中，机器上面的主内存总量，这样的解决方法，相当脆弱，并且总是会存在可拓展性问题。

更进一步地说，一个有趣的话题在于图数据分析的理想方法，它可以被用于构建特定领域的图数据分析来，具体的案例就是 GraphX[^64]，或者 GraphLab[^105]，它们同时可以被连接到某一种数据库上面来。亦或者，我们可以使用 D4M[^95]当中支持的数组分析，或者[^90]中建议的表分析，来模拟此类代码。我们真诚祝愿解决方案的探索空间，得到一个爆发式的增长，并让商业市场，成为最终的仲裁者！

最后来说，绝大多数的数据分析代码，使用 MPI 来展开交流的工作，而数据库则总是使用 TCP/IP 协议。同时并行计算密集分析包，如 ScaLAPACK，总是将数据组织成计算集群当中，跨节点的块循环组织[^40]。就我所知道的那样，没有一个数据库支持块循环分区。而消除分析包与数据库之间的阻抗不匹配将会是一个有趣的研究领域，这也是英特尔赞助的 ISTC 组织在大数据领域的研究目标[^151]。

由 Joe Hellerstein 撰写的技术评论

2015年11月6日

对于这个领域而言，无论是从商业角度的方面，或者研究机会的方面，我与 Mike 均存在差异程度很大的不同意见。最基本的，我建议在这个区域使用“大帐篷式”的方法。而数据库分支的人在这个领域存在着良多的贡献，而如果我们与其它人能够通力合作的话，我们就可以把事情做的更好。

让我们首先对于工业界做一个审视。首先，我们在这个所讨论的那种高级的数据分析并不会像 Miki 所提出的那样，能够把商业智能分析行业取代掉。商业智能行业依旧处于一个健康发展的阶段。而更为重要的事情在于，正如著名的统计学家 John Tukey 在他的开创性数据分析基础工作中提出的那样，图表相较于复杂的统计模型而言，往往更有价值。

因此务必尊重图表！

还而言之，先进的数据分析与数据科学的市场，确实处于一个增长的状态，并准备发生变化。但与商业智能分析市场不同的地方在于，这并不是数据库技术目前发挥重要作用的类别，这一领域的现任者，就是 SAS，它是一家每年收入达到数十亿美元的公司，而非常它并不是一家数据库公司。当风险投资家审视这一领域的公司的时候，它们实际上就在寻找“下一个SAS”。SAS的用户并非数据库用户。而像R这样的开源替代品的用户，也绝对不是数据库的用户。如果你像 Mike 那样假设，“数据科学家将会想着使用数据库技术的话” --- 尤其是一个单机的“分析型数据库” --- 你将会是逆潮流而行。

而如果想要更自然地进入到高级数据分析市场之中，我们可以询问自己：SAS面临的严重威胁究竟是什么？谁能够从企业当前花费的现金流当中分得一杯羹？下面就是一些我们所需要思考起来的要点：

  1. 开源统计编程：这就包含了 R 与 Python 数据科学的生态系统（NumPy, SciKit-Learn, iPython Notebook).这些解决方案，在当前的情况之下，规模并不是很大，但是它们依旧在积极努力地解决这些限制。这个生态系统的发展，可能会比 SAS 更快。
  2. 大数据平台更为紧密地整合。当数据量足够庞大的时候，性能要求可能会把用户“拖入”到新的平台之中 --- 也就是一个已经在其组织当中，托管大数据的平台。因此，人们对于 Spark/MLLib, PivotalR/MADlib 和 Vertica dplyr 等平台的“DataFrame”接口产生了浓厚的兴趣。请注意，高级数据分析社区，高度偏向于开源。而云也是一个有趣的平台，注意 SAS 在这里并不占据着什么优势。
  3. 数据分析服务。在这里，我所代指的就是以数据分析方法作为核心的交互式在线服务：推荐系统，实时性欺诈检测，预测性的设备维护等，凡此种种。这一领域对于响应时间，请求的拓展，容错性以及持续的发展，都有着严格的系统要求，而SAS等产品，则无法满足这些要求。而到了今天，这些服务在很大程度上面，都是使用自定义代码构建的。而这些并非是跨行业的 --- 绝大多数公司，不能招募到在这个级别层次工作的开发人员。因此，在绝大多数用例之中，从表面来看，我们似乎可以把这项技术商品化。但是对于这个市场来说，现在做出决断，依旧是为时过早 --- 分析服务平台是否能够变得足够简单，以便于用于商品的部署。如果这方面的科学技术不断发展的话，基于云的数据分析服务，也有可能在某个重大的时刻，迎来革命性的发展机遇。

而在研究的方面，我认为，跳出数据库的框架思考，展开积极的合作，是一件重要的事情。这对我而言，这件事情不言而喻。因此计算领域的每一个子领域，几乎都在用某一种方式，展开大数据分析，而来自于各个领域的聪明人，正在迅速学习自己关于数据和规模的经验。和这些人，我们既可以与他们工作地相当愉快，也可以选择对他们视而不见，而后者显然对我们不利。

因此，数据库领域的研究能够在这个领域的那些方面产生重大的影响呢？在我看来，下面的这些可能性就很好，这就包括了：

  1. 一条新的处理可伸缩性的路径。我们已经成功地展现了并行的数据流 --- 想想看 MADlib，MLlib 以及 Ordonez 在 Teradata5 上面所展开的一系列工作 --- 他们可以在不对系统架构展开暴力调整的情况之下，为实现可拓展的分析工作，带来很大的帮助。知道这一点，是很有用的事情。而放眼前方，我们可以做一些相较于，比基于分区数据上面的并行数据流更快、更具有可拓展性的事情吗？这说的就是 Hogwild!它在这里引发了很多最大的兴奋；注意这项工作已经跨越了数据库与机器学习社区。
  2. 为数据分析服务准备的分布式架构服务。正如我在这里提及的那样，数据分析服务对于创新而言，是一个有趣的充满机遇的领域。这方面的系统基础设施问题相当公开。分析服务架构的主要组成部分，究竟是什么？它们究竟如何整合到了一起？各个组件之间需要什么样的数据一致性？所谓的参数服务器在目前，就是一个有趣的话题，但是它仅仅解决了其中一部分的问题。而我们在在线服务、模型的演变以及部署方面，已经有了一些初步的工作。我希望在未来能够展开更多的这方面工作。
  3. 数据分析的生命周期与元数据的管理。这是我与 Mike 达成了一致意见的领域。数据分析往往是一项人员密集型的工作，除了核心统计的建模之外，还牵涉到数据探索与转换。在这个过程之中，我们需要管理大量的上下文，以便于了解如何在一系列工具与系统中开发模型与数据产品。数据库社区对这一领域，具有高度相关的观点，包括工作流的管理，数据沿袭以及物化视图的维护。VisTrails就是该领域研究的一个例子，而目前它就在实践当中应用。这也是行业当中，急需特需的领域，尤其是考虑到该领域当中，数据分析工作和系统在现实世界当中的多样性的工作。

参考​

[1] P. Baumann, A. Dehmel, P. Furtado, R. Ritsch, and N. Widmann. The multidimensional database system rasdaman. In SIGMOD, 1998.
[2] T. Chilimbi, Y. Suzue, J. Apacible, and K. Kalyanaraman. Project adam: Building an efficient and scalable deep learning training system. In OSDI, 2014.
[3] J. Choi et al. ScaLAPACK: A portable linear algebra library for distributed memory computers—design issues and performance. In Applied Parallel Computing Computations in Physics, Chemistry and Engineering Science, pages 95– 106. Springer, 1996.
[4] J. Dean, G. Corrado, R. Monga, K. Chen, M. Devin, M. Mao, A. Senior, P. Tucker, K. Yang, Q. V. Le, et al. Large scale distributed deep networks. In Advances in Neural Information Processing Systems, pages 1223–1231, 2012.
[5] J. Duggan and M. Stonebraker. Incremental elasticity for array databases. In Proceedings of the 2014 ACM SIGMOD international conference on Management of data, pages 409–420. ACM, 2014.
[6] A. Elmore, J. Duggan, M. Stonebraker, M. Balazinska, U. Cetintemel, V. Gadepally, J. Heer, B. Howe, J. Kepner, T. Kraska, et al. A demonstration of the BigDAWG polystore system. In VLDB, 2015.
[7] J. E. Gonzales, R. S. Xin, D. Crankshaw, A. Dave, M. J. Franklin, and I. Stoica. Graphx: Unifying data-parallel and graph-parallel analytics. In OSDI, 2014. [8] J. M. Hellerstein, C. R´e, F. Schoppmann, D. Z. Wang, E. Fratkin, A. Gorajek, K. S. Ng, C. Welton, X. Feng, K. Li, et al. The MADlib analytics library: or MAD skills, the SQL. In VLDB, 2012. [9] A. Jindal, P. Rawlani, E. Wu, S. Madden, A. Deshpande, and M. Stonebraker. Vertexica: your relational friend for graph analytics! In VLDB, 2014.
[10] J. Kepner et al. Dynamic distributed dimensional data model (D4M) database and computation system. In Acoustics, Speech and Signal Processing (ICASSP), 2012 IEEE International Conference on, pages 5349–5352. IEEE, 2012.
[11] Y. Low, D. Bickson, J. Gonzalez, C. Guestrin, A. Kyrola, and J. M. Hellerstein. Distributed graphlab: a framework for machine learning and data mining in the cloud. In VLDB, 2012.
[12] B. Recht, C. Re, S. Wright, and F. Niu. Hogwild: A lock-free approach to parallelizing stochastic gradient descent. In Advances in Neural Information Processing Systems, pages 693–701, 2011.
[13] N. Siva. 1000 genomes project. Nature biotechnology, 26(3):256–256, 2008.
[14] M. Stonebraker, S. Madden, and P. Dubey. Intel big data science and technology center vision and execution plan. ACM SIGMOD Record, 42(1):44–49, 2013.
[15] The SciDB Development Team. Overview of SciDB: large scale array storage, processing and analysis. In SIGMOD, 2010